1. Field of the Invention
The present application relates to a method, system and computer program for adding data to a data container.
2. Description of the Related Technology
It is often desirable to add data to an already existing data container. For example, it is often desirable in a communications network to intercept a message between two communicating entities and add data to a data container in the message. For example, a user equipment in the communications network may request media content from a content provider. A server can intercept the request for media content, forward it onto the content provider, intercept the response from the content provider and add data to the response before sending the response onto the user equipment.
Such alteration could, for example, be used for advertising purposes. A user may load a web page using a web browser and the browser may send a Hypertext Transfer Protocol (HTTP) request message to an origin server (i.e. a content provider) in order to retrieve specified content. An advertising server may intercept such a message and forward it onto the origin server. The advertising server may intercept a corresponding HTTP response message and modifies the HTTP response message to include an advertisement. The loaded web page in the user's web browser may then display the advertisement.
Typically, a HTTP response is compressed with a specified content-encoding in order to reduce the size (i.e. reduce the number of bytes) of the HTTP response. This can be useful in general to reduce congestion in the network. Some of the most commonly used content encoding techniques for compression are the “gzip” (GNU-zip) encoding and the “deflate” encoding as defined in the RFC (Request For Comments) 2616 standards document. A content encoding of gzip comprises a data stream compressed in accordance with RFC (Requests for Comments) 1951 embedded in a container in accordance with RFC 1952. A content encoding of ‘deflate’ comprises a data stream compressed in accordance with RFC 1951 but embedded in a container in accordance with RFC 1950.
When modifying a HTTP response having a payload with a specified content-encoding so as to include additional data, the payload must first be decompressed, the additional data added to the data of the decompressed payload and the modified response (i.e. having the data as well as the additional data) is then recompressed before being transmitted to its destination. In general, this procedure is necessary because simply pre-pending or appending the additional data to the received HTTP response would produce a data container that is non-compliant with the content encoding technique used to encode the original payload. Such decompression and recompression consumes processing power, memory and adds latency to the network signaling. The decompression and recompression can also cause “bloating” of the HTTP response where the recompression is not as effective as the original compression and thus the delivered content (i.e. the modified HTTP response) is larger than the original HTTP response. Such bloating also adds latency and congestion in the communications network.